package cn.ycc1.functionlibrary.collections;

/**
 * Storing Data Using the Collections Framework
 * @author ycc
 * @date 2025/3/7
 *
 */
public class StoringData {
    /**
     * Introducing the Collections Framework
     * The Collections Framework is the most widely used API of the JDK. Whatever the application you are working on is,
     * odds are that you will need to store and process data in memory at some point.
     *
     * The history of data structures goes back nearly as far back as computing itself. The Collections Framework is an
     * implementation of the concepts on how to store, organize, and access data in memory that were developed long before
     * the invention of Java. The Collections Framework does this in a very efficient way, as you are going to see.
     *
     * The Collections Framework was first introduced in Java SE 2, in 1998 and was rewritten twice since then:
     *
     * in Java SE 5 when generics were added;
     * in Java 8 when lambda expressions were introduced, along with default methods in interfaces.
     * These two are the most important updates of the Collections Framework that have been made so far. But in fact,
     * almost every version of the JDK has its set of changes to the Collections Framework.
     *
     * You will learn in this part are the most useful data structures the Collections Framework has to offer, along with the
     * patterns you will be using to manipulate this data in your application.
     *
     * The first thing you need to know is that, from a technical point of view, the Collections Framework is a set of
     * interfaces that models different way of storing data in different types of containers. Then the Framework provides
     * at least one implementation for each interface. Knowing these implementations is as important as the interfaces,
     * and choosing the right one depends on what you need to do with it.
     */

    /**
     * Finding Your Way in the Collections Framework
     * The amount of interfaces and classes in the Collections Framework may be overwhelming at first. Indeed, there are many
     * structures available, both classes and interfaces. Some have self-explanatory names, like LinkedList, some are carrying
     * behavior, like ConcurrentHashMap, some may sound weird, like ConcurrentSkipListMap.
     *
     * You are going to use some of these elements much more often than others. If you are already familiar with the Java
     * language, you probably came across List, ArrayList and Map already. This tutorial focuses on the most widely used
     * structures of the Collections Framework, the ones you are going to use daily as a Java developer, and that you need
     * to know and understand best.
     *
     * That being said, you need to have the big picture of what is there for you in the Collections Framework.
     *
     * First, the framework consists of interfaces and implementations. Choosing the right interface means you need to know
     * what functions you want to bring to your application. Is what you need consists in:
     *
     * storing objects and iterating over them?
     * pushing your object to a queue and popping them?
     * retrieving them with the use of a key?
     * accessing them by their index?
     * sorting them?
     * preventing the presence of duplicates, or null values?
     * Choosing the right implementation means you need to know how you are going to use these functionalities:
     *
     * Will accessing your objects be done by iterating, or random, indexed access?
     * Will the objects be fixed at the launch of your application, and will not change much over its lifetime?
     * Will the amount of objects be important with a lot of checking for the presence of certain objects?
     * Is the structure you need to store your objects in will be accessed concurrently?
     * The Collections Framework can give you the right solution to all of these problems.
     *
     * There are two main categories of interfaces in the Collections Framework: collections and maps.
     *
     * Collections are about storing objects and iterating over them. The Collection interface is the root interface of this
     * category. In fact, the Collection interface extends the Iterable interface, but this interface is not part of the
     * Collections Framework.
     *
     * A Map stores an object along with a key, which represents that object, just as a primary key represents an object in
     * a database, if you are familiar with this concept. Sometimes you will hear that maps store key/value pairs,
     * which exactly describes what a map does. The Map interface is the root interface of this category.
     *
     * There is no direct relationship between the interfaces of the Collection hierarchy and the Map hierarchy.
     *
     * Along with these collections and maps, you also need to know that you can find interfaces to model queues and stacks
     * in the Collection hierarchy. Queues and stacks are not really about iterating over collections of objects, but since
     * they have been added to the Collection hierarchy, it turns out you can do that with them.
     *
     * There is one last hierarchy that you also need to know, which is the Iterator hierarchy. An iterator is an object that
     * can iterate over a collection of objects, and it is part of the Collections Framework.
     *
     * That makes two main categories, Collection and Map, a subcategory, Queue, and a side category, Iterator.
     */

    /**
     * Avoiding Using Old Interfaces and Implementations
     * The Collections Framework was only introduced in Java 2, meaning that there was a life before it. This life consisted
     * in several classes and interfaces that are still in the JDK, to preserve backward compatibility, but that you should
     * not use anymore in your applications.
     *
     * Those classes and interfaces are the following:
     *
     * Vector and Stack. The Vector class has been retrofitted to implement the List interface. If you are using a vector in
     * a non-concurrent environment, then you can safely replace it with ArrayList. The Stack class extends Vector and should
     * be replaced by ArrayDeque in non-concurrent environments.
     * The Vector class uses the Enumeration interface to model its iterator. This interface should not be used anymore:
     * the preferred interface is now the Iterator interface.
     * HashTable: This class has been retrofitted to implement the Map interface. If you are using instances of this class in
     * a non-concurrent environment, then you can safely replace its use with HashMap. In a concurrent environment,
     * ConcurrentHashMap can be used as a replacement.
     */

    /**
     * Why Choose a Collection Over an Array?
     * You may be wondering why you should bother learn the Collection Frameworks when you may have the feeling that putting
     * your data in a good old array does the job.
     *
     * The fact is, in any case, if you have a solution that is simple, that you master well, and that fits your needs,
     * then you should definitely stick with it!
     *
     * What can a collection do for you, that an array cannot?
     *
     * A collection tracks the number of elements it contains
     * The capacity of a collection is not limited: you can add (almost) any amount of elements in a collection
     * A collection can control what elements you may store in it. For instance, you can prevent null elements to be added
     * A collection can be queried for the presence of a given element
     * A collection provides operations like intersecting or merging with another collection.
     * This is just a small sample of what a collection can do for you. In fact, since a collection is an object and given
     * that an object is extensible, you can add any operation you need on most of the collections provided by the JDK.
     * It is not possible to do this with an array, because an array is not an object in Java.
     */
}
